-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New lint: unnested_or_patterns
#5378
Conversation
46aa951
to
edc2802
Compare
CI seems happy. 🎉 |
☔ The latest upstream changes (presumably #5380) made this pull request unmergeable. Please resolve the merge conflicts. |
edc2802
to
26a873b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(note to self: some mistakes I made to fix before merging)
☔ The latest upstream changes (presumably #5294) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for taking so long for the review. I don't have an excuse, just wasn't really motivated to review PRs recently.
This looks really good. It'll need a rebase + cargo dev update_lints
and you may want to address your own comments 😉
26a873b
to
ecabed6
Compare
61fb7ad
to
a9ca832
Compare
r? @phansch No need to review the lint itself, I already did that. A second pair of eyes on fixing the dogfood fallout would be great though! (I finished this lint, since Centril currently takes a break from OSS and this is too good to let it go to waste) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I just have to get used to or_patterns
more - in some cases I find them harder to parse in my head than the un-nested version. Did you have the same feeling @flip1995? (in any case, r=me for the dogfood changes)
help: nest the patterns | ||
| | ||
LL | if let box (0 | 1 | 2 | 3 | 4) = Box::new(0) {} | ||
| ^^^^^^^^^^^^^^^^^^^^^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoa these suggestions are nice 🤯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they are built by modifying the AST and then pretty printing it IIUC. Centril definitely knows what he's doing 😄
["as_ptr", "unwrap"] | ["as_ptr", "expect"] => { | ||
lint_cstring_as_ptr(cx, expr, &arg_lists[1][0], &arg_lists[0][0]) | ||
}, | ||
["as_ptr", "unwrap" | "expect"] => lint_cstring_as_ptr(cx, expr, &arg_lists[1][0], &arg_lists[0][0]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example here, is that really less complex than before? In my mind I first have to think about the precedence to figure out what's going on. Maybe it just takes some time to get used to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it just takes some time to get used to it.
I think that's it. But especially this example is really nice IMO. I think it expresses more the thought of ""as_ptr"
is the first part, followed by "unwrap"
OR "expect"
", instead of "it's either an "as_ptr", "unwrap"
array OR an "as_ptr", "expect"
array. I can see why one would prefer the later way of writing this though.
What I struggeled with on first reviewing this was a pattern like:
(A | B, C | D) => { ... }
Because this is combinatorially evaluated (A+C, A+D, B+C, B+D), which may not be directly obvious, if your not used to this kind of pattern.
@bors r=flip1995,phansch |
📌 Commit a9ca832 has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
When rustfixing this lint on nightly, we will always get errors if
should we move this to pedantic/nursery until |
It shouldn't lint, if the |
Hm, I can't reproduce this with the clippy of latest nightly. But when I use the master toolchain and use master-clippy (I build clippy using rustc master and put the bins in |
} | ||
|
||
fn lint_unnested_or_patterns(cx: &EarlyContext<'_>, pat: &Pat) { | ||
if !cx.sess.opts.unstable_features.is_nightly_build() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, we should check, if the feature is enabled here. In that case, this was an oversight on my side.
changelog: Adds a lint
unnested_or_patterns
, suggestingSome(0 | 2)
as opposed toSome(0) | Some(2)
. The lint only fires on compilers capable of using#![feature(or_patterns)]
.The lint is primarily encoded as a pure algorithm which to unnest or-patterns in an
ast::Pat
(fn unnest_or_patterns
) through aMutVisitor
. After that is done, and assuming that any change was detected, thenpprust::pat_to_string
is used to simply convert the transformed pattern into a suggestion.The PR introduces a module
utils::ast_utils
with a bunch of functions for spanless & nodeless equality comparisons of ASTs.cc rust-lang/rust#54883